From: "Stefan Stuntz"Date: Tue, 12 Dec 1995 16:44:28 +0100 X-Mailer: IntuiNews 1.3b Beta 3 (5.11.95) Subject: Re: Clipping in SubClasses Message-Id: <64540122@magic.informatik.tu-muenchen.de> Organization: Home of MUI Resent-Message-Id: <"n3xuz2.0.TT.1_Upm"@sunsite> Resent-From: mui@sunsite.Informatik.RWTH-Aachen.DE Reply-To: mui@sunsite.Informatik.RWTH-Aachen.DE X-Mailing-List: archive/latest/50 X-Loop: mui@sunsite.informatik.rwth-aachen.de Precedence: list Resent-Sender: mui-request@sunsite.Informatik.RWTH-Aachen.DE Content-Type: text Content-Length: 1744 X-Lines: 45 Status: RO Stephen Vermeulen wrote in article <9512111927.AA13480@boris.psg.datap.ca>: > > Georg Kraemer wrote > > > > > 1.) What is the correct way of clipping inside a SubClass ? Currently > > > I simply set Clipping to the inner of the gadget, but this may be > > > conflict with Clipping of virtual Groups for example. Of cause > > > clipping is only done during the DRAW Method. > > > > Use MUI_AddClipping()/MUI_RemoveClipping() from muimaster.library, never > > use InstallClipRegion() in MUI-Windows. > > > > These do not appear in the mui31dev.lha (from AMINET) autodocs, what else is > missing from them too? Do you have a more up-to-date set of autodocs > available elsewhere? Unfortunately not. :( APTR MUI_AddClipping (struct MUI_RenderInfo *mri,WORD left,WORD top,WORD width,WORD height); VOID MUI_RemoveClipping (struct MUI_RenderInfo *mri,APTR handle); and APTR MUI_AddClipRegion (struct MUI_RenderInfo *mri,struct Region *r); VOID MUI_RemoveClipRegion (struct MUI_RenderInfo *mri,APTR handle); do basically the same, once with coordinates and once with a struct Region. Note that after MUI_AddClipRegion, you no longer need to worry about freeing the structure, MUI_RemoveClipRegion will do this for you. The MUI_AddXXX return a handle which must be passed to the MUI_RemoveXXX function call. Adding clip regions cannot fail. You can nest clip regions, MUI will automatically take care of that and "AND" new regions to existing ones. Thus, the clipping calls work fine in virtual groups. > I am trying to write a custom class that implements the ListView with > horizontal scrollablity, That's heavy stuff. In fact, MUI should offer this but due to lack of time on my side, it still doesnt. :( -- Greetings, Stefan From: "Stefan Stuntz" Date: Thu, 14 Dec 1995 11:15:26 +0100 X-Mailer: IntuiNews 1.3b Beta 3 (5.11.95) Subject: Re: Clipping in SubClasses Message-Id: <64540270@magic.informatik.tu-muenchen.de> Organization: Home of MUI Resent-Message-Id: <"O5R273.0.MO3.Eg_pm"@sunsite> Resent-From: mui@sunsite.Informatik.RWTH-Aachen.DE Reply-To: mui@sunsite.Informatik.RWTH-Aachen.DE X-Mailing-List: archive/latest/65 X-Loop: mui@sunsite.informatik.rwth-aachen.de Precedence: list Resent-Sender: mui-request@sunsite.Informatik.RWTH-Aachen.DE Content-Type: text Content-Length: 298 X-Lines: 13 Status: RO Boris Folgmann wrote in article > > APTR MUI_AddClipping (struct MUI_RenderInfo *mri,WORD left,WORD > top,WORD width,WORD height); > > VOID MUI_RemoveClipping (struct MUI_RenderInfo *mri,APTR handle); > > When do I call them? Show/Hide? Never. Only durig MUIM_Draw. -- Greetings, Stefan From: Jason S Birch Message-Id: <199602090445.MAA10168@decadence> Subject: Re: MUI FAQ To: svermeul@suntzu.psg.datap.ca (Stephen Vermeulen) Date: Fri, 9 Feb 1996 12:45:51 +0800 (WST) In-Reply-To: <199602081714.KAA08466@alien.psg.datap.ca> from "Stephen Vermeulen" at Feb 8, 96 10:14:39 am X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Lines: 80 Status: RO Content-Type: text/plain; charset="US-ASCII" Content-Length: 3083 > I would like to see: > > 1. Notes on clipping > 2. Notes on writing custom classes > 3. Pointers to source code examples for custom classes > 4. Using BOOPSI in MUI > 5. Corrections to the MUI docs (missing/obsolete attributes...) > 6. Using datatypes with mui custom classes Good, that's what I like to see. BTW, since I've already had to work out the clipping deal for a previous question I got for the FAQ, here's the answer I gave: --- Ok, here's the easiest way: Inside your MUIM_Draw method, having something along the lines of: APTR clip = MUI_AddClipping(muiRenderInfo(obj), left, top, width, height); where (left, top) are the starting co-ordinates, and (0,0) is the top left of the object's area. width is the width of the clipping region, and height is it's height. When you have finished (again, still inside MUIM_Draw) you do: MUI_RemoveClipping(muiRenderInfo(obj), clip); Note that clip is the handle that was originally returned by MUI_AddClipping(). That's it. You can nest clippings simply by calling it again (with a different handle), MUI will take care of combining them. You can also use a struct ClipRegion. I've included Stefan's notes on the subject at the end of this message. As to why you need to do this, I'd say that it's because outside of your MUI_Draw routine, MUI is free to do anything it wants with your area. It can stick it into a virtual group, it can disappear altogether (when iconified or the window is closed), anything. If there were ClipRegions hanging around that MUI hadn't installed, I imagine it would make all this rather difficult. I'd say it's the same reason why you can't draw to your area outside of your MUI_Draw routine. Here are Stefan's notes: APTR MUI_AddClipping (struct MUI_RenderInfo *mri,WORD left,WORD top,WORD width,WORD height); VOID MUI_RemoveClipping (struct MUI_RenderInfo *mri,APTR handle); and APTR MUI_AddClipRegion (struct MUI_RenderInfo *mri,struct Region *r); VOID MUI_RemoveClipRegion (struct MUI_RenderInfo *mri,APTR handle); do basically the same, once with coordinates and once with a struct Region. Note that after MUI_AddClipRegion, you no longer need to worry about freeing the structure, MUI_RemoveClipRegion will do this for you. The MUI_AddXXX return a handle which must be passed to the MUI_RemoveXXX function call. Adding clip regions cannot fail. You can nest clip regions, MUI will automatically take care of that and "AND" new regions to existing ones. Thus, the clipping calls work fine in virtual groups. --- > > APTR MUI_AddClipping (struct MUI_RenderInfo *mri,WORD left,WORD > top,WORD width,WORD height); > > VOID MUI_RemoveClipping (struct MUI_RenderInfo *mri,APTR handle); > > When do I call them? Show/Hide? Never. Only durig MUIM_Draw. - From: ss37@irz.inf.tu-dresden.de (Sven Steiniger) Date: Tue, 16 Jan 1996 11:38:19 +0100 Message-Id: <199601161038.LAA18730@irz102.inf.tu-dresden.de> To: mui@sunsite.Informatik.RWTH-Aachen.DE Subject: Window pattern Resent-Message-Id: <"GBwuf.0.Gy.s0u-m"@sunsite> Resent-From: mui@sunsite.Informatik.RWTH-Aachen.DE Reply-To: mui@sunsite.Informatik.RWTH-Aachen.DE X-Mailing-List: archive/latest/169 X-Loop: mui@sunsite.informatik.rwth-aachen.de Precedence: list Resent-Sender: mui-request@sunsite.Informatik.RWTH-Aachen.DE Content-Type: text Content-Length: 494 X-Lines: 18 Status: RO Hello, Did anyone know how to avoid that MUI draws a background-pattern into the window ? (I create a custom class (from mui-window-class). This install a new clipRegion in the window and waits for draw-messages (MUI_Draw or my own PREVIEW_Draw) and then it clear this Region and draw the new content. The problem is that MUI first draws his window-pattern and then I come and clear this area. This looks really bad and is very slow) Sven Steiniger. ---- From: Jason S Birch Message-Id: <199601161323.VAA15463@decadence> Subject: Re: Window pattern To: mui@sunsite.Informatik.RWTH-Aachen.DE Date: Tue, 16 Jan 1996 21:23:00 +0800 (WST) In-Reply-To: <199601161038.LAA18730@irz102.inf.tu-dresden.de> from "Sven Steiniger" at Jan 16, 96 11:38:19 am X-Mailer: ELM [version 2.4 PL25] Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Resent-Message-Id: <"negU23.0.Xi2.LQz-m"@sunsite> Resent-From: mui@sunsite.Informatik.RWTH-Aachen.DE Reply-To: mui@sunsite.Informatik.RWTH-Aachen.DE X-Mailing-List: archive/latest/170 X-Loop: mui@sunsite.informatik.rwth-aachen.de Precedence: list Resent-Sender: mui-request@sunsite.Informatik.RWTH-Aachen.DE X-Lines: 23 Status: RO Content-Type: text/plain; charset="US-ASCII" Content-Length: 935 > Hello, > > Did anyone know how to avoid that MUI draws a background-pattern into the > window ? > (I create a custom class (from mui-window-class). This install a new clipRegion > in the window and waits for draw-messages (MUI_Draw or my own PREVIEW_Draw) > and then it clear this Region and draw the new content. The problem is that > MUI first draws his window-pattern and then I come and clear this area. This > looks really bad and is very slow) Perhaps you should be creating an Area or Group subclass and putting that into the window to receive MUI_Draw, rather than the window itself? > Sven Steiniger. > ss37@irz.inf.tu-dresden.de -- Jason S Birch From: "Stefan Stuntz" Date: Tue, 16 Jan 1996 15:16:31 +0100 X-Mailer: IntuiNews 1.3b Beta 3 (5.11.95) Subject: Re: Window pattern Message-Id: <81318141@magic.informatik.tu-muenchen.de> Organization: Home of MUI Resent-Message-Id: <"M_sVk3.0.gs3.Vk4_m"@sunsite> Resent-From: mui@sunsite.Informatik.RWTH-Aachen.DE Reply-To: mui@sunsite.Informatik.RWTH-Aachen.DE X-Mailing-List: archive/latest/171 X-Loop: mui@sunsite.informatik.rwth-aachen.de Precedence: list Resent-Sender: mui-request@sunsite.Informatik.RWTH-Aachen.DE Content-Type: text Content-Length: 783 X-Lines: 22 Status: RO Sven Steiniger wrote in article <199601161038.LAA18730@irz102.inf.tu-dresden.de>: > Did anyone know how to avoid that MUI draws a background-pattern into the > window ? > (I create a custom class (from mui-window-class). This install a new > clipRegion > in the window and waits for draw-messages (MUI_Draw or my own PREVIEW_Draw) > and then it clear this Region and draw the new content. The problem is that > MUI first draws his window-pattern and then I come and clear this area. This > looks really bad and is very slow) If you set #define MUIA_FillArea 0x804294a3 /* V4 ... BOOL */ /* private */ for an object, area class will not draw its background. This attribute is private but will become public nex version and works since muimaster.library V4. -- Greetings, Stefan From: "Stefan Stuntz" Date: Tue, 13 Feb 1996 13:43:53 +0100 X-Mailer: IntuiNews 1.3b Beta 5 (3.1.96) Subject: Re: New errors introduced in 3.2? Message-Id: <81319257@magic.informatik.tu-muenchen.de> Organization: Home of MUI Resent-Message-Id: <"-LoYp1.0.2c4.4W88n"@sunsite> Resent-From: mui@sunsite.Informatik.RWTH-Aachen.DE Reply-To: mui@sunsite.Informatik.RWTH-Aachen.DE X-Mailing-List: archive/latest/287 X-Loop: mui@sunsite.informatik.rwth-aachen.de Precedence: list Resent-Sender: mui-request@sunsite.Informatik.RWTH-Aachen.DE Content-Type: text Content-Length: 993 X-Lines: 26 Status: RO Terje Pedersen wrote in article <1158.6616T1367T2188@login.eunet.no>: > >> Also getting the visual area of the scroll group seems to cause > >> problems as _mleft(virtualgroup)+_mwidth/_mtop+_mheight seems to > >> include the scroll bar which I'm not too interested in.. > > >Of course a scrollgroup contains the bars, thats why its a scrollgroup, > >not a virtualgroup. Besides from that, I cannot quiet believe that MUIs > > Well, I want to know the exact portion of the virtual group that is visible > and draw this part of the whole area. Why? The virtual groups clips anyway, just draw everything you want in your draw method. If you want to optimize your drawing, parse the currently installed clip region in your window and only draw the parts contained in the clip. struct Region *clip = (_window(obj)->Flags & WFLG_WINDOWREFRESH) ? _window(obj)->WLayer->DamageList : _window(obj)->WLayer->ClipRegion; if (!clip) draw_everything(); else draw_stuff_in_clip(); Greetings, Stefan